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PROCEDE D' ADMINISTRATION DE RESEAUX A LAIDE D 'AGE NTS INTELLIGENTS. 

L'invention conceme un procede d'administration de 
reseau faisant intervenir une plural ite d'utilisateurs du re- 
seau et une pluralite de ressources et/ ou de services dispo- 
nibles dans le reseau et destinees a etre utilisees par lesdits 
utiiisateurs, caracterise en ce qu'il comporte des etapes 
consistant a informer le systeme de gestion de reseau des 
besoins des utiiisateurs. et a informer les utiiisateurs des 
ressources et/ ou services disponibles dans le reseau, de 
sorte que ledit systeme de gestion de reseau puisse de fa- 
con autonome executer des operations de gestion aptes a 
optimiser le fonctionnement du reseau en fonction des be- 
soins des utiiisateurs et des ressources et/ ou services dis- 
ponibles dans le reseau. 
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La presente invention concerne les precedes et dispositifs de gestion de reseaux 
d'ordinateurs, et phis particulierement la gestion de la qualite de service dans un reseau. 

Phis precisement, Tinvention concerne un procede permettant d'introduire et de 
5 prendre en compte les besoins des utilisateurs de reseaux, aussi bien utilisateurs finaux que 
fournisseurs de services, dans une structure de gestion de reseau, afin de permettre a des 
applications de gestion de reseau de decider en direct des operations appropriees de 
gestion de reseau, sans intervention humaine. 
Etat de la Technique: 

10 L' interconnexion mondiale des ordinateurs est aujourd'hui en passe de deverrir 

une realite. Les reseaux font et feront de plus en plus partie de renvironnement quotidien, 
et permettront de gerer des applications pour une variete croissante de taches, allant par 
exemple jusqu'a la gestion telecommandee de Pequipement menager et electrique des 
maisons. De tels reseaux, en tant que systemes distribues, necessitent surveillance et 

15 administration. Or les reseaux prives, comme par exemple les reseaux locaux ou ceux des 
petites entreprises, n'ont pas les memes besoins en terme d'administration que les reseaux 
a TecheUe mondiale. Pourtant, si la phipart des peripheriques partageables en reseau sont 
administrables (via SNMP, pour « Simple Network Management Protocol » en 
terminologie anglosaxonne), seules quelques plateformes d'administration existent, 

20 specifiquement conqjes pour les grands reseaux. 

La gestion de reseaux et la gestion de systemes (distribues ou non) ont ete 
pendant longtemps des activates different es et separees, meme si elles presentaient des 
interactions. Recemment, les deux activites ont connu une certaine integration, de sorte 
qu'il est maintenant possible a partir d'une plateforme de gestion unique de gerer de fa^on 

25 homogene des reseaux et des systemes Des exemples de ce type integration sont foumis 
par I' integration de NETVTEW (solution de gestion de reseau commercialisee par IBM) 
avec TME10 (gestion de systemes distribues, de TTVOLI), ou par OPEN VIEW (solution 
de gestion de reseau de Hewlett Packard) avec TNG L'ni center (gestion de systemes 
distribues de Computer Associates) D'autres plateformes similaires existent sur le marche, 

30 mais aucune n'integre une forme de sensibilite ou de « conscience » des besoins des 
utilisateurs finaux, c'est a dire des profils d 1 utilisateurs exprimant la fa<?on dont TutilLsateur 
prevoit d'utiliser un systeme distribue. 
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Tnconvenients de 1'etat de la Technique: 

L'absence de communication entre les applications d' administration et les 
systemes d'administration est la cle d'un probleme majeur et encore sans solution a ce 
jour en matiere d'administration de reseaux. 

Ainsi, dans les plateformes d'administration de reseau disponibles aujourd'hui, 
toutes les fonctions de gestion de reseau ne sont pas couvertes, car les plateformes 
existantes se focalisent sur la simple surveillance du reseau et sur le rapport d'evenements. 

En outre, aucune application d'administration de reseau connue n'est capable de 
gerer efficacement un reseau heterogene. De plus, les produits existants, bien que de 
fonctionalhe Hmitee, sont chers et consommateurs de ressources et ne sort pas adaptes a 
de petits reseaux. 

Enfin, dans les systemes et precedes d'administration de reseaux de I'etat de la 
technique, il n'est pas tenu compte des services qui seront utilises par les applications 
installees sur le reseau, ni surtout d'un niveau de qualite de service attendu par un 
utilisateur ou une application. De ce fait, les applications, qui pourtant dependent de phis 
en plus du reseau, ont difficilement acces a des informations le concemant. 

Une application a rarement la possibilrte de determiner a Tavance si les 
ressources qu'elle requiert sort disponibles. Par exemple, une application reseau qui 
repose sur un systeme de fichiers distribue n'a aucun moyen de savoir si la qualite de 
services requise n'est pas en train de se degrader. De ce fart, il arrive que la moindre 
degradation des ressources du reseau peut dramatiquement affecter la stabilke de 
F application, voire Fempecher totalement de fonctionner 
Arridre plan de l'invention: 

En raison des differents inconvenients mentionnes ci-dessus, une nouvelle 
approche de gestion qui est deja souhahable aujourd'hui dans les environnements complexes 
de reseaux, deviendra vhale dans le fiitur. En fait, il est probable qu'a mesure ou Fusage de 
Tordinateur de reseau (NC: Network Computer en terminologie anglosaxonne) tend a se 
developper, le reseau lui-meme va revetir une importance de phis en phis grande pour les 
utilisateurs finaux, et reciproquement 

Ainsi, il va devenir impossible de concevoir une infrastructure de gestion de 
reseau qui ne prenne pas en compte les besoins des utilisateurs finaux, puLsque ces derniers 
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represented la phis importante source d'information , pour conserver le fonctionnement 
optimal d'un environnement de reseau. 

Or ce fonctionnement depend a la fois des besoins des utilisateurs en termes 
de parametres de qualite de service, que des caracteristiques de Foffre de service disponible 
dans le reseau pour les utilisateurs a chaque instant. Et 0 est clair que les problemes 
d'administration lies a Fapparition d'applications mobiles ne peuvent plus etre trakes 
eflBcacement par les anciennes approches de gestion statique et centralisee des reseaux 
Buts de P invention: 

Le but principal de I'invention est par consequent de proposer un procede 
et des mecamsmes de gestion de reseau permettant de resoudre F ensemble des 
inconvenients des systemes d'administration de reseau connus dans Fetat de la technique. 
Phis particulierement, un des buts de Finvention est de proposer un procede 
d'administration de reseau simple, permettant une meilleure integration et collaboration 
entre les applications, et des platefoimes d'administration extensibtes et peu couteuses Un 
autre but de Finvention est de proposer un procede d'administration permettant de remplir 
automatiquement des taches d'administration aptes a prendre en compte les besoins des 
utilisateurs du reseau. 

Un autre but de Finvention est de proposer une plateforme d'adminisatration de 
reseau qui soit a la fois flexible et extensible pour pouvoir prendre en compte Fajout de 
ressources ou de services, et economique 

D'autres buts et avantages de Finvention vont apparaitre a la lecture de la 
description suivante fahe a titre d'exemple non limhatif, et aux dessins ci-annexes, dans 
lesquels: 

- La figure 1 represente un environnement reseau du type de ceux ou le procede 
de gestion selon Finvention peut etre mis en oeuvre, 

- La figure 2 represente sous forme schematique une architecture de gestion y 
compris les principaux agents permettant de mettre en oeuvre Finvention, 

- La figure 3 represente sous forme schematique les elements d'un contexte 
d'application utilise pour mettre en oeuvre le procede selon Finvention, 

introduire tableau page 92 

- La figure 4 represente sous forme schematique les elements d une contexte de 
fournisseur de service utilise pour mettre en oeuvre le procede selon Finvention, 
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- La figure 5 represente un contexte d'application et un constexte de foumisseur 
de service, pour deux types differents de services: r impression et le serveur de fichiers, 

- La figure 6 represente sous forme schematique la structure d'un agent 
intelligent pouvant etre utilise pour mettre en oeuvre le procede selon Finvention, 

5 - La figure 7 represente r integration d'agents intelligents dans un exemple 

d'environnement de reseau; 

Principe de la solution: 

L'invention decrite phis en detail ci-dessous est la premiere tentative de gestion 

integrant non seulement la gestion de reseaux et de systemes distribues, mais va plus loin 
10 en integrant egalement des informations concernant la fa^on dont les utilisateurs prevoient 

d'utiliser des services disponibles dans un environnement de reseau d'entreprise, par 

exemple comme cehii represente en figure 1 . Selon l'invention, il est propose une methode 

et des outils pour introduire dans Finfrastucture de gestion de reseau, une cormaissance ou 

une « conscience » des besoms des utilisateurs finaux et des ressources des fourrrisseurs de 
15 services, afin de permettre de decider a la volee des operations appropriees de gestion de 

reseau, telles que la surveillance, la commande, le diagnostic, ou la reconfiguration du 

reseau, et ce sans aucune intervantion humaine. 

Dans la suite, on definira par mesure de simplicite la gestion de reseau avec 

cormaissance des besoins des utilisateurs par la terminologie de « gestion avertie », qui 
20 serait mieux representee en terminologie anglosaxonne par F expression « aware 

management ». 

L'inventiion conceme un procede d'administration de reseau faisant intervenir 
une phiralhe d'utilisateurs du reseau et une pluralite de ressources et/ou de services 
disponibles dans le reseau et destinees a etre utilisees par lesdits utilisateurs, caracterise en 
25 ce qu^il comporte des etapes consistant a informer le systeme de gestion de reseau des 
besoins des utilisateurs, et a informer les utilisateurs des ressources et/ou services 
disponibles dans le reseau, de sorte que ledit systeme de gestion de reseau puisse de 
fapon autonome executer des operations de gestion aptes a optimiser le 
fonctionnement du reseau en fonction des besoins des utilisateurs et des ressources 
30 et/ou services diponibles dans le reseau. 

Selon d'autres caracteristiques du procede degestion selon l'invention: 
. - il comporte des etapes consistant a: 
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- rassembler les besoins des utilisateurs a partir des applications 
utilisatrices de ressources, et les capacites de prestations des ressources et/ou services a 
partir des applications prestataires de ressources et/ou de services; 

- transmettre lesdhs besoins et capacites des applications a un 
environnement de gestion de reseau; 

- au niveau de 1' environnement de gestion de reseau, traiter les 
informations revues et decider des operations de gestion a effectuer pour que 
r environnement de reseau fonctionne comme requis par les applications utilisatrices; 

- au cas ou 1' environnement de reseau ne peut pas fonctionner comme 
demande, en informer les applications utilisatrices et/ou les applications prestataires. 

- pour rassembler les besoins des utilisateurs a partir des applications 
utilisatrices de ressources, on utilise une structure d'information dynamique QdS 
representative des besoins de Qualite de Service (QdS), comprenant un en-tete de 
contexte d'application et un bloc d'information representatif des specifications de qualite 
de service pour chaque service parmi une pluralite de services. 

- ledit bloc d'information representative des besoins de qualite de service 
comport e une sequence de dimensions de QdS, chaque dimension de QdS contenant une 
sequence de Domaines, et chaque Domaine contenant une sequence d'attributs de QdS. 

- pour rassembler les capacites de prestations des ressources et/ou services a 
partir des applications prestataires de ressources et/ou de services, on utilise une 
structure d'information dynamique representative des offres de qualite de service a 
1' attention des utilisateurs, comprenant un en-tete de contexte de fournisseur de service, 
un bloc d'information representatif des specifications de qualite de service offertes par 
chaque service disponible, et un un bloc d'information representatif des specifications de 
qualite de service pour chaque service parmi une pluralite de services 

- pour traiter les informations revues et decider des operations de gestion a 
effectuer, on elabore des taches de gestion abstraites a 1'aide d' agents autonomes qui 
prennent en compte les besoins de qualite de servie QdS des utilisateurs, et les offres de 
service dans 1' environnement du reseau 

- de preference, lesdits agents sont des agents intelligent, comportant : 

- une couche avertie permettant d'acquerir les besoins des utilisateurs du 
reseau et les offres de services, 
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- une couche deliberative chargee de creer des taches de gestion, 

- une couche operationndle executant les taches de gestion crees par la 
couche deliberative. 

Selon up aspect de P invention, la saisie des besoins des utilisateurs se fait par 
5 l'intennediaire d'une interface homme-machine comprenant un moyen d' entree 
d'information et un moyen d'affichage. 
Description det *iH^ He* figure- 

On se refere a la figure 1. On a represente dans cette figure un exemple de 
structure de reseau permettant de mettre en oeuvre l'inventioa L'environnement 1 

10 represente est compose de plusieurs domaines utilisateurs, tel que cetui du cote gauche de 
la figure, un domaine de serveurs 2 ou sont situes les serveurs d'entreprise, et un reseau 
principal 3 permettant de federer toutes les communications sort pour acceder a des 
ressources du reseau dans Fentreprise ou a Fexterieur 

Les utilisateurs finaux ou les applications expriment leurs besoins par 

15 F intermediate d'une structure d 'information qui sera appelee dans la suite un contexte 
d'application ou Desiderata de Qualite de Service (QdS). Cette structure d'information 
detaille les services et les attributs de QdS associes qui sont consider es appropries pour 
assurer un comportement correct de la part d'une application. Un Desiderata de QdS est 
1 'element qui permet a une plateforme de gestion d'atteindre une connaissance concernant 

20 les services en cours d 'utilisation, leur utilisateur, et la fa^on dont ces services sont utilises. 
De ce fait, il est egalement possible, grace a Tinvention, d'en deduire le degre de 
satisfaction des utilisateurs finaux de renvironnement de reseau. II doit etre rappele que ce 
qui a ete jusqu'a present evalue dans Petat de la technique, n'est que le degre de 
satisfaction du foumisseur de services, au lieu du degre de satisfaction des utilisateurs 

25 finaux 

La definition d'une structure capable de porter une combinaison de requetes pour de 
multiples services ayant chacun ses caracteristiques propres, implique la conception d'une 
structure d'information dynarrrique pour les Desiderata de QdS. 

30 On se refere a la figure 2, qui represente de fa$on schematique Tarchitecture 

d'un ensemble de gestion de reseau integrant les principaux elements necessaires pour la 
mise en oeuvre du procede selon 1' invention. 
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Cette architecture se focalise sur les agents AIs de QdS. Les AIs de QdS 
resoivent, via une couche CORB A les besoins des applications (Application Contexts) et 
des fournisseurs de service (Service Provider Contexts). lis dialoguent ensuite (toujours 
via CORBA) avec un serveur SQL qui joue le role dinterface entre l'AI et des agents 

5 SNMPs classiques. Ce serveur traduh les requetes de l'AI (exprimees en SQL) en 
requetes de type SNMP a l'attention des agents SNMP, recueille les resuhats et les 
communique (sous forme SQL) a l'AI. Pour de nombreuses raisons, un AI peut avoir a 
communiquer avec un autre AI. Dans ce cas, la communication se fait via des messages 
au format KQML encapsulant des messages specifies soit en KQML, soit en GDL.. Un 

10 agent Interface d' Agent a ete con<?u pour assister les managers humains pour 
communiquer avec les agents intelligents, a 1'aide d'une interface graphique d' utilisateur 
(voir plus loin). 

L' Agent Interface est un agent sous forme d'applet qui permet a un manager a 
priori humain d'interroger et d'interagir avec des Agents Intelligents. La communication 
15 proprement elite se fait au moyen de messages par exemple au format KQML. 

Le routeur de messages inter-agents, ou AMR (Agent Message Router) 
est une application specialisee (un assistant de communication), qui a la reception d*un 
message provenant d*un agent, le redirige vers l'agent destinataire. Les messages repus 
sont geres dans une file d'attente conservee sur le systeme de fichiers. 
20 Le serveur SQL joue le role d*un interprete entre AI et agents SNMP, le 

premier parlant SQL, les autres SNMP. 

L'tnterface utilisateur est une interface sous forme d'aplet (petite 
application) qui permet a un utilisateur de specifier directement ses desiderata en matiere 
de QdS. Cette interface n'a de vertu que demonstrative, puisqu'idealement ces desiderata 
25 seront essentiellement specifies directement par les applications 

La connaissance des besoins des utilisateurs est une notion qui est absente des 
systemes connus de gestion de reseau. De ce fait, la gestion dhe avertie est un effort pour 
donner un sens a cette expression dans le cadre de systemes de gestion de reseau, de sorte 
que le resuhat de la gestion du reseau devienne plus satisfaisante du point de vue d T un 
30 utilisateur final. 

On definit par consequent la « gestion avertie » comme etant la capadte d'un systeme 
de gestion de decider de ses activites pour un environnement de reseau, sur la base des 
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besoins courants des utilisateurs. Cette gestion avertie prend en compte des questions 
comme: qui sont les utilisateurs finaux ? Quels sont leurs besoins courants de service ? 
comment sont-ils logiquement organises ? Ou sont-ils situes, etc. 

Les besoins des utilisateurs et les offres de services devant etre pris en compte, il 

5 devient necessaire de trouver une fa^on d'exprimer les besoins des utilisateurs et les oflfres de 
service a Paide de structures d'information respectives appropriees. Ces structures 
d 1 information sont decrites en relation avec les figures 3 et 4 De fapon generate, chaque 
entite de QdS doit etre identifiee par un nom unique, qui est compose de son propre nom phis 
une concatenation des noms de toutes les entites QdS qui la contienent Ainsi, le nom d'un 

10 Domaine de QdS doit etre du type [Nom de Service ][Nom de Dimension QdS][Nom de 
Domaine QdS]. Les besoins de QdS et les entites de service possedent egalement un en-tete 
d'entite contenant des informations generiques par rapport a eux-memes 

Toua-s les specifications de QdS doivent suivre les recommendations ci-dessus 

On se refere a la figure 3 pour decrire la structure d'un besoin ou desiderata de QdS. 

15 II contient les specifications de service de chaque service que I'application requiert pour 
fonctionner correct ement Une specification de service contient elle-meme une liste de 
conditions (contraintes) implicites sur des attributs (parametres) de QdS associes au 
service. Ces attributs de QdS sont logiquement organises de facon hierarchique en 
Dimension de QdS et Domaine de QdS. Toutes les specifications de QdS doivent suivre 

20 ces regies. L'avantage d'une telle approche est qu'elle permet a TAgent de travailler a un 
niveau eleve d*abstraction. Ainsi un Agent peut se voir amene a prendre une decision en 
se basant seulement sur la Dimension de QdS plutot que sur chaque attribut de QdS de 
chaque Domaine de QdS de la Dimension de QdS 

Les besoins de QdS sont a la base d'une gestion avertie, au sens de Tinvention 

25 Une telle entite comporte toute rinformation concernant tous les services utilises, 
comment et par qui ils sont utilises, et avec quel niveau de priorite. 

La structure d*un contexte d'application (ou besoin de QdS) comporte un en-tete 
de contexte d* application^ ou des informations generales concernant Papplication 
d'utilisateur final sont stockees, et des besoins de services, dans lesquels sont stockees 

30 les specifications detaillees de chaque service La table 1 ci-dessous donne le detail de ce 
premier niveau de contexte d' application 
Table 1: 
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Nom 


Signification 


En-tete de contexte 
d'application 


Description generate de l'application presente dans 
Penvironnement de reseau 


Besoins de Services 


Bloc d'informations ou sont inclus les specifications de QdS pour 
chaque service 


La table 2 represente les attribute de P en-tete de contexte duplication qui identifie 
l'application d'utilisateur final et Putilisateur qui utilise l'application. 


Table 2: 




Nom 


Signification 


Nom d' Application 


Nom que Pediteur de logiciel a donne a l'application 


Type d' application 


Caracterisation du role de V application dans Penvironnement de 
reseau (session d'utilisateur) 


Identification 
d' Application 


Distingue deux applications du meme type lancees dans le meme 
hote. 


Nom d'utilisateur 


Nom de Putilisateur qui est responsable de cette application ou 
est en train de Putiliser 


IdentijBant 
d'utilisateur 


Identifiant de Pentreprise de Putilisateur 


Nom de Host 


Nom du noeud de reseau ou Papplication est situee 


Priorite 


Priorite donnee par Putilisateur a cette application 



Les besoins de service sont composes d'une sequence de contextes de service, 
representes dans la table 3 . 



10 Table 3: Principaux blocs d'un contexte de service 



Nom d'attribut 


Signification 


En-tete de contexte 
de service 


attributs generiques concernant un service selcectionne 
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Sequence de 
dimensions de QdS 


les dimensions de QdS constituent le premier niveau de detail 
ayant trait a des demandes d'utilisateurs pour un service donne 


Sequence de 
Ressources 


Ressources de service requises par V application de ce service 


Table 4: attributs definis dans Ten-tete de contexte de service 


Nom d'attribut 


Signification 


En-tete de contexte 
de service 


attributs generiques concernant un service selcectionne 


Sequence de 
dimensions de QdS 


les dimensions de QdS constituent le premier niveau de detail 
ayant trait a des demandes d'utilisateurs pour un service donne 


Sequence de 
Ressources 


Ressources de service requises par Implication de ce service 


Table 5: Attributs definis dans le contexte de service 


Nom 


Signification 


Service 


nom generalement accept e pour le service 


Fournisseur de 
Service 


nom du fournisseur de service, quelquefois identique au nom du 
sy st erne qui Theberge 


Priorite 


Priorite du service pour 1'application qui Tutilise 


Media 


decrit le type de media dont le service a besoin, tel que donnees, 
video, audio, etc. 


Engagement 


decrit la classe d'engagement que r application utilisant ce service 
attend a partir de la plateforme de gestion. tel que meilleurs 
efforts, statistique, deterministe 



On se refere a la figure 4 pour decrire la structure d 1 information representative du 
contexte de fourrrisseurs de service Les Dimensions de QdS et Domaines de QdS 



2774191 



n 

specifies dans le Contexte ^application correspondent evidemment a ceux definis par les 
fournisseurs de service. Ces derniers expriment leur capacites dans des Contextes de 
fournisseurs de service, qui contiennent des attributs de QdS (hierarchiquement organises 
en Dimension de QdS et Domaines de QdS) que le fournisseur de service est capable 
5 d'offiir. Les fournisseurs sont responsables de rinstrumentation du service, le doivent 
non seulement specifier les attributs de QdS ies plus appropriees pour le service, mais 
aussi les outils de mesure permettant de les surveiller. 

La figure 5 recapitule sous forme schematique les structures d'information 
representatives d'un contexte duplication et du contexte de fournisseur de service, 
10 pour deux exemples de services souvent utilises en pratique: un service de serveur de 
fichiers (note DFS), et un service d'impression (note DPRINT1NG). 

Le procede de gestion selon Tinvention et les entites et structures d'information 
utilises peuvent etre de preference mis en oeuvre a l'aide d' agents autonomes intelligents, 
notes AI. L'AI est une composante centrale de la strategic de gestion. Ses proprietes 
15 sont les suivantes: 

Reactif, des l'apparition d'un probleme l'agent doit definir les mesures 
appropriees a prendre et eventuellement employer les outils a sa dispositions pour agir 
sur la source du probleme. 

Proactif, il doit anticiper l'apparition des problemes et chercher a ameliorer les 
20 performances du systeme avant que les valeurs critiques des seuils ne soient atteints. 

Autonome, il doit posseder une certaine autonomic de decision quant aux 
reponses a apporter en cas de pannes, et ne notifier le manager que lorsque le probleme 
depasse ses competences. En revanche, il doit toujours notifier les applications des 
moindres degradations voire interruptions d f un service dont il garantit la QdS 
25 La figure 6 donne une representation schematique d'un mode de realisation 

d'un agent intelligent pouvant etre utilise pour mettre en oeuvre le procede de gestion 
selon Tinvention. On peut distinguer 3 couches dans Tarchitecture d\m Agent 
Intelligent (AI) 

La premiere couche, que Ton appellera la «partie sensible» (awareness layer en 
30 terminologie anglo-saxonne), se compose essentiellement du Gestionnaire de contextes 
(Context Manager). Ce Gestionnaire oflfre phisieurs interfaces, accessibles par tous les 
acteurs definis plus haut, a savoir les applications utilisateurs, les fournisseurs de service 
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et les applications ^administration. Grace a ces interfaces, le Gestionnaire de contextes 
peut gerer des informations oriente services de haut niveau. - 

-La «partie deliberative)) (deliberative layer) forme la seconde couche, ou Ton 
retrouve principalement le Gestionnaire de buts ^administration (Goal Manager). 

-La «partie executive)) (operational layer) est la troisieme et derniere couche, 
et est formee par les procedures d'administration. Chaque but d'administration de la 
couche superieure est associee a une intention d'administration qui represente les 
procedures d'administration decidees par l'Al. 

On va maintenant decrire de fa^on plus detaillee chacune des trois parties 
des agents intelligents utilises dans le cadre de Pinvention: 
1) Partie avertie: 

L' Agent Intelligent (AI) etant typiquement destine a etre place dans un environnement 
distribue, on doit par consequent le doter de mecanismes lui permettant de detecter les 
caracteristiques de son environnement, et en particulier, dans le cas present, les 
desiderata ou besoins des applications 

Comme il est aujourdliui attendu que les systemes distribues du futur seront 
bases sur un paradigme de communication via un «langage neutre», tel que CORBA, I'AI 
doit lui aussi proposer des interfaces, specifies en CORBA IDL, aux apphcations, 
foumisseurs de services et systemes ^administration 

Ces interfaces fournissent des methodes pour la negociatiorv publication et 
mise a jour des contextes. Les manipulateurs de contextes (Service, Dimension de QdS 
et Domaine de QdS) analysent les contextes regus et les stockent dans des Bases de 
contextes. lis passent ensuite une reference des contextes fraichement re?us au 
Gestionnaire de buts d'administration 
Le Gestionnaire de contextes - « Context Manager » 

Le gestionnaire de contexte est charge de collect er les desiderata des applications 
et foumisseurs, sous la forme de contextes ^applications et de contextes de foumisseurs 
de service, de les interpreter et de les passer a la couche inferieure 
2) La Partie deliberative: 

- Gestionnaire de buts d'administration « Goal Manager » 

A la reception d\in contexte duplication (via la couche superieure), ou d\m but 
d'administration d*un tiers agent (via le module de communication), le Gestionnaire de 
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buts d'administration doit decider si un but d'administration doit localement etre cree ou 
non, en se basant entre autres choses sur un ensemble de politiques definies par les 
administrateurs de reseau. S f il decide de le creer, il le signale au module «Memoire», qui 
le conservera dans sa Base de categories mentales. Ainsi I'AI pourra verifier au besoin si 
un but d'administration n'est pas deja planifie. 

Une autre decision est alors a prendre par I'AI: faut-il traiter localement le but 
d'administration, le deleguer a un autre AI, ou les deux a la fois? En fait, la decision de 
deleguer un but sera prise si l'agent ne peut acceder a certaines ressources du systeme 
distribue car ne se trouvant pas dans son domaine, ou si I'AI estime ne pas etre 
suffisamment efficace pour traiter le but demande, car par exemple trop eloigne des 
ressources a gerer. Une fois de plus, cette decision est basee entre autres sur des 
politiques definies par les administrateurs de reseaux 

Module de communication - »Conversation Dispatcher » Le gestionnaire 
de buts d'administration implemente une interface dediee aux echanges de categories 
mentales Cette interface doit etre accessible a tous les agents -puisqu'elle autorise les 
autres agents a deleguer un but d'administration, ou encore a obtenir des informations sur 
un but d'administration et les outils de mesure de service associes. 

Decision de creation de but d'administration: Un but d'administration 
comporte un ensemble de conditions («desiderata») portant sur des attributs de QdS. 
Cette information est direct ement associee aux conditions definies par un contexte 
d'application. Ce dernier peut donner lieu a un ou plusieurs buts d'administration, 
puisqu'il peut y avoir plusieurs ensembles d'attributs de QdS (i e des Domaines de QdS), 
et qu\m but d'administration depend au moins d'un dornaine de QdS (il sera par la suite 
traduit en procedures d'administration) 

En se basant sur le contexte d'application (nom du service, les clients, les 
fournisseurs, ainsi que les attributs, domaines et dimensions de ~OdS) et sur les 
politiques du manager, le Cerveau doit alors decider si oui ou non la creation d'un 
nouveau but d'administration s'avere necessaire 

Pour une implementation possible, on peut decider d'implementer la regie 
suivante: / % A1 decide de creer un nouveau but: 

a) s'il n*y a aucun but d'administration deja present dans la Base de categorie mentale 
comportant le triplet (nom du service, dimension de QdS, domaine de QdS) 
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ou bien: 

b) si un tel triplet existe, mais que raccomplissement du but associe n'implique pas 
l'accomplissement du nouveau but. 

On peut voir le triplet ci-dessus comme un index global de but 
d'administration. L'AI peut utiliser cet index lors de la creation d\in nouveau but pour 
rechercher dans la Base de categorie mentale si des buts similaires ne seraient pas deji en 
cours. Cest rinformation minimale (extraite du contexte ^application) qui permet de 
distinguer deux buts similaires. Bien sur, cet index depend de Pinterpretation de 
rinformation contenue dans le but... 

^implication b) est un des elements qui font Intelligence de PAL H dit que 
si un but doit etre accompli, tout autre but implique par lui ria pas besoin d'etre 
accompli. Par exemple, si une application requiert un temps de reponse de 10ms pour le 
service NFS (serveur de ficheirs), et qu'il existe deja un but qui accomplit 5ms, le premier 
but est implique par le but deja existant et n'a par consequent pas besoin d'etre cree. 
Cette regie est clairement specifique a un but, Le la definition de cette implication peut 
etre differente (et differemment implementee) pour chaque combinaison de Pindex... 

Decision de delegation de but d' administration Le modele de decision 
verifie si le foumisseur de service requis est bien situe dans le domaine gere par PAgent. 
L' Agent Intelligent est conscient de la presence de foumisseurs de services puisqu'il 
re<?oit des contextes de service de la part de chaque foumisseur de service. Par 
consequent la decision a prendre est implementee en recherchant dans la base des 
contextes de service le nom du foumisseur de service 

- si le foumisseur de service se situe dans le domaine gere par Tagent, le 
but sera traite localement, puisque Tagent est capable de recuperer les outils qui 
instrumenteront le service ; 

si le foumisseur de service appartient a un domaine de gestion sur lequel 
Tagent n'a aucun droit, le but doit etre delegue. 

Par exemple, si une application a besoin d'acceder au serveur Web d*un autre 
domaine de gestion avec un temps de reponse donne, au moins deux Agents (PAgent 
gerant le domaine ou se trouve Papplication, et et celui gerant le domaine ou se situe le 
serveur Web) devront cooperer (dans le sens ou ils devront travailler de concert) pour 
atteindre Pobjectif demande. 
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Implementation Le « Centre d'Operations » est en fait initialement assez 
« stupide », mais est pret a recevoir un moteur d'inference ou tout autre systeme de 
manipulation de connaissances. 

C'est au Centre de Decisions de gerer les priorites fixees par les managers, 
applications et fournisseurs de services, et les conflits qui peuvent en resulter. Par 
exemple, un fournisseur d'acces Internet souhaitera la plus haute qualite possible pour le 
service WEB, tandis qu*un etudiant imprimant son rapport de stage privilegera pour un 
temps le service depression ©PRINTING, pour rebasculer sur le service WEB une 
fois le rapport imprime. 

C'est encore au Centre de Decisions de decider de fusionner ou non des buts de 
gestions, ou encore de tenter de synthetiser ses croyances pour en degager les croyances. 
Dans une implementation possible, le Cerveau decide systematiquement de fusionner les 
buts En ce qui concerne le second point, le Cerveau est aujourd'hui capable de 
synthetiser les peri odes de non disponibilite d*un service donne, capacite qui peut 
facilement etre etendue a des croyances plus generates 

Memoire (Memory) La memoire de 1AJ est un module qui pennet 
d'interroger et de manipuler la base de connaissance interne (KB) de TAJ C'est elle qui 
conserve et maintient les categories mentales de I'agent 

Implementation La Memoire est aujourd'hui implementee sous la forme 
d*un tableau associatif complexe, qui pennet d'associer a une cle soit une expression, soit 
un autre sous-tableau associatif complexe. 

Module de communication (« Conversation Dispatcher ») Le module de 
conversation de l'AI est un module qui permet de communiquer avec d'autres agents. 

3) La Partie executive 

La partie executive se fonde essentiellement sur le module Effecteur (« Engine »). 
II peut efFectivement etre compare aux bras de l'AI, car il dispose de tous les elements 
necessaires pour mesurer la QdS, et au besoin de I'ameliorer. 
Procedures d'administration: D y a trois types de procedures d'administration 

- Surveillance et mesure 

- Analyse et diagnostic 

- Reparation et configuration 
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Implementation On associe aux procedures coadministration des classes jouant le role d' 
outils de mesure de QdS (« QoS Meter »), d' outils de diagnostic - (« QoS Diagnosis »). 
et d' outil de configuration - (« QoS Configure ») 

5 On se refere a la figure 7 pour une illustration de l'utilisation d 'agents 

intelligents en liaison avec un environnement de gestion de reseau donne. 

Conclusion 

L'invention propose pour la gestion des QdS une solution basee sur des 
10 Agents Intelligents (AIs), jouant le role d'assistants vis-a-vis des applications, et 
permettant ainsi le maintien d*une QdS la plus proche possible de la demande. Pour 
pouvoir gerer cette QdS individuellement par application, les AIs ont besoin de connaitre 
leurs desiderata. Les structures dlnformation choisies a cette fin sont du type contexte, 
organisees suivant les divers services requis. 
15 L'invention teUe que decrite plus haut repond a ses objectifs, et permet entre 

autres de faire en sorte que les reseaux puissent "etre au courant" des besoins et des 
comportements des applications, ce qui peut etre consider* comme une forme 
d '« intelligence » a fort potentiel, non encore explore. Cela permet d'informer les 
applications des degradations de la qualite de service, et dV faire face, par exemple par la 
20 generation d'evenements ou alarmes, non seulement en cas de pannes graves mais aussi 
des que des degradations de la qualite de service se font sentir de faccon individueUe, ce 
qui est total ement impossible aujourdliui 
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REVENDICATIONS 

1. Procede d'administration de reseau faisant intervenir une pluralite d'utilisateurs du 
reseau et une pluralite de ressources et/ou de services disponibles dans le reseau et destinees a 

5 etre utilisees par lesdits utilisateurs, caracterise en ce qu'il comporte des etapes consistent 
a informer le systeme de gestion de reseau des besoins des utilisateurs, et a informer les 
utilisateurs des ressources et/ou services disponibles dans le reseau, de sorte que ledit 
syst&me de gestion de reseau puisse de fa$on autonome executer des operations de 
gestion aptes a optimiser le fonctionnement du reseau en fonction des besoins des 

10 utilisateurs et des ressources et/ou services diponibles dans le reseau. 

2. Procede selon la revendication 1, caracterise en ce qu'il comporte des Stapes 
consistent a: 

- rassembler les besoins des utilisateurs a partir des applications utilisatrices de 
ressources, et les capacites de prestations des ressources et/ou services a partir des 

15 applications prestataires de ressources et/ou de services; 

- transmettre lesdits besoins et capacites des applications a un environnement de 
gestion de reseau; 

- au niveau de Fenvironnement de gestion de reseau, trait er les informations 
re<?ues et decider des operations de gestion a effectuer pour que V environnement de 

20 reseau fonctionne comme requis par les applications utilisatrices, 

- au cas ou P environnement de reseau ne peut pas fonctionner comme demande, 
en informer les applications utilisatrices et/ou les applications prestataires. 

3. Procede selon la revendication 2, caracterise en ce que pour rassembler les 
besoins des utilisateurs a partir des applications utilisatrices de ressources, on utilise une 

25 structure d'information dynamique QdS representative des besoins de Qualite de Service 
(QdS), comprenant un en-tete de contexte duplication et un bloc d'information 
representatif des specifications de qualite de service pour chaque service parmi une 
pluralite de services. 

4, Procede de gestion selon la revendication 3, caracterise en ce que ledit 
30 bloc dWormation representative des besoins de qualite de service comporte une 

sequence de dimensions de QdS, chaque dimension de QdS contenant une sequence de 
Domaines, et chaque Domaine contenant une sequence d'attributs de QdS. 
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5. Precede selon la revendication 2, caracterise en ce que pour rassembler les 
capacites de prestations des ressources et/ou services a partir des applications 
prestataires de ressources et/ou de services, on utilise une structure d'information 
dynamique representative des offres de qualite de service a Inattention des utilisateurs, 
comprenant un en-tete de contexte de fournisseur de service, un bloc d' information 
representatif des specifications de qualite de service offertes par chaque service 
disponible, et un un bloc d' information representatif des specifications de qualite de 
service pour chaque service parmi une pluralite de'services. 

6. Procede selon Tune quelconque des revendications precedentes, 
caracterise en ce que pour traiter les informations re9ues et decider des operations de 
gestion a effectuer, on elabore des taches de gestion abstraites a Taide d'agents 
autonomes qui prennent en compte les besoins de qualite de servie QdS des utilisateurs, 
et les offres de service dans Fenvironnement du reseau. 

7. Procede selon la revendication 6, caracterise en ce que lesdits agents 
sont des agents intelligents, comportant : 

- une couche avertie permettant d'acquenr les besoins des utilisateurs du 
reseau et les offres de services, 

- une couche deliberative chargee de creer des taches de gestion; 

- une couche operationnelle executant les taches de gestion crees par la 
couche deliberative 

8. Procede selon Tune quelconque des revendications precedentes, caracterise 
en ce que la saisie des besoins des utilisateurs se fait par rintermediaire d'une interface 
homme-machine comprenant un moyen d'entree d'information et un moyen d'aflBchage. 
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